「走れ！プロジェクトマネージャー！」

　プロジェクトマネジメントマガジンvol.4が、Amazonから家に届きました。今回の特集は”要求⇒仕様”を「見える化」する！というものです。この「見える化」という単語、流行っていますね。可視化という言葉は以前からあるので、別段新しいことをするわけではないのですが、今までより対象が広がったのだと思います。
　今までは、スケジュールを可視化しようとか、コストを可視化する、というように使われていたのだと思いますが、このように「要求」とか「仕様」といった、今まで「口頭」で済まされることが多かったものも、どんどん「見える化」していこうということです。
　特にこの「要求」と「仕様」を見える化する背景には、このフェーズでプロジェクトの成功 or 失敗のほとんどが決まってしまうからです。そしてこのフェーズは、今までプロジェクトとして見なされないことが多かった。これらのフェーズが終わったあとからプロジェクトマネージャーが任命され、「頑張ってくれ！」と渡されていたのです。

　プロジェクトの失敗はそれまでに決まっているのに「頑張ってくれ！」もなにもないもんですが、そういったことが行われていたのは事実でした。また、設計フェーズに進んでから、要求、仕様といったフェーズに戻ってくることが多いのも事実です。
　ところが実際には、このフェーズに時間をかけないプロジェクトが多数見受けられます。「時間がない」とか、「ユーザが協力的でない」といったことを理由に、この時間を端折ってしまうことが多いようです。
　よく「PDCA」サイクル、なんて言いますが、この「P」を端折ってしまうのですから、サイクルが回るわけがありません。
　さて、ではこれはプロジェクトマネージャー一人の責任でしょうか？「協力的でないユーザ」がいるのも、プロジェクトマネージャーの責任でしょうか。
　ここはあえて厳しい言い方をさせていただきます。そうです、プロジェクトマネージャーの責任です。これは、プロジェクトマネージャー一人でやれ！と言っているのではありません。そういう問題があることを早期にアラートをあげて、メンバーの協力を得るなり、上長の助けを求めるなり、またはチームをファシリテートしていくなりで、コンセンサスを取り、プロジェクトが円滑に進むように「促進」しなければならない職務なのです。
　それは凄く大変なことでありますが、逆に考えると素晴らしい名誉であり、自分を試す良い機会に恵まれた、ということなのでもあると思います。そしてそれを実行をするために、プロジェクトマネジメントの本が山のように出版され、あれこれ手法が共有されているのだと思います。
　あえて言います、手法だけでプロジェクトは進みません。誰より強く「プロジェクトの成功」に対する思いがないと進みません。しかし、思いがある人を助けるのは「手法」であり、「ツール」です。飛行機でいうところの、強靱な胴体を持っていても、両翼がなければ飛べません。そして、素晴らしい両翼があっても、胴体がなければ意味を成しません。
　プロジェクトを見える化する。それは、プロジェクトを成功させる手法の一つだと、強く思いました。